SherbyNet - /page/wikibook/entry.mu

Micron Document

`:top

`!Client-to-client protocol`! (`!CTCP`!) is a special type of communication between `F33f`_`[Internet Relay Chat`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Internet_Relay_Chat]`_`f (IRC) clients.

CTCP is a common protocol implemented by most major IRC clients in use today. CTCP extends the original IRC protocol by allowing users to query other clients or channels, this causes all the clients in the channel to reply the CTCP, for specific information. Additionally, CTCP can be used to encode messages that the raw IRC protocol would not allow to be sent over the link, such as messages containing `F33f`_`[newlines`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Newline]`_`f or the `F33f`_`[byte`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Byte]`_`f value 0 (NULL). CTCP does not establish a direct connection between clients; however, it is commonly used to negotiate `F33f`_`[DCC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Direct_Client-to-Client]`_`f connections.

CTCP allows users to query a remote client about the version of the client they are using (via `B100`F9d9CTCP VERSION`f`b), or the time (via `B100`F9d9CTCP TIME`f`b), among other things. It is also used to implement the /me command (via `B100`F9d9CTCP ACTION`f`b).

>>Contents

• `F0af`_`[History`#history]`_`f

• `F0af`_`[Structure`#structure]`_`f

• `F0af`_`[Common CTCP commands`#common-ctcp-commands]`_`f

• `F0af`_`[VERSION`#version]`_`f

• `F0af`_`[TIME`#time]`_`f

• `F0af`_`[PING`#ping]`_`f

• `F0af`_`[DCC CHAT`#dcc-chat]`_`f

• `F0af`_`[DCC SEND`#dcc-send]`_`f

• `F0af`_`[DCC XMIT`#dcc-xmit]`_`f

• `F0af`_`[Passive DCC`#passive-dcc]`_`f

• `F0af`_`[File servers (FSERVs)`#file-servers-fservs]`_`f

• `F0af`_`[See also`#see-also]`_`f

• `F0af`_`[References`#references]`_`f

• `F0af`_`[External links`#external-links]`_`f

-─

>>History

`F33f`_`[ircII`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=IrcII]`_`f was the first IRC client to implement the CTCP and DCC protocols.`:cite-ref-1[`F5bf`_`[1`#cite-note-1]`_`f] The CTCP protocol was implemented by Michael Sandrof in 1990 for ircII version 2.1,`:cite-ref-2[`F5bf`_`[2`#cite-note-2]`_`f] while the DCC protocol was implemented by Troy Rollo in 1991 for version 2.1.2.`:cite-ref-3[`F5bf`_`[3`#cite-note-3]`_`f]

>>Structure

A CTCP message is implemented as a `B100`F9d9PRIVMSG`f`b or `B100`F9d9NOTICE`f`b where the first and last characters of the message are `F33f`_`[ASCII`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=ASCII]`_`f value 0x01. Additionally, characters which would not be allowed in the IRC protocol are escaped. Since a `B100`F9d9NOTICE`f`b as the standard should not generate a reply, CTCP messages are sent as `B100`F9d9PRIVMSG`f`b and the reply is implemented with a `B100`F9d9NOTICE`f`b instead of a `B100`F9d9PRIVMSG`f`b.

A CTCP query is initiated on most clients as follows:

`B100`F9d9CTCP <target> <command> <arguments>`f`b

Where `*<target>`* is the target nickname or channel, `*<command>`* is the CTCP command (e.g. `B100`F9d9VERSION`f`b), and `*<arguments>`* are additional information to be sent to the `*<target>`*.

>>Common CTCP commands

CTCP commands and replies are client-specific; as such, depending on the IRC client, some of the following CTCP commands may not trigger a response, or will be formatted differently than what is shown here.

>>>VERSION

A `B100`F9d9CTCP VERSION`f`b request will return the name and version of the IRC client the target is using, and in some cases technical information such as the `F33f`_`[operating system`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Operating_system]`_`f, `F33f`_`[clock rate`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Clock_rate]`_`f, `F33f`_`[CPU Manufacturer`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=CPU]`_`f and `F33f`_`[CPU architecture`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=CPU_architecture]`_`f/`F33f`_`[instruction set`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Instruction_set]`_`f.

A sample reply for a `B100`F9d9CTCP VERSION`f`b request to a target that uses the `F33f`_`[HexChat`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=HexChat]`_`f client is:

`B100`F9d9VERSION HexChat 2.9.1 [x86] / Windows 8 [1.46GHz]`f`b

>>>TIME

A `B100`F9d9CTCP TIME`f`b request will return the `F33f`_`[local time`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Time_zone]`_`f of the target computer. Depending on the IRC client, the reply may consist of the `F33f`_`[date`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Calendar_date]`_`f, the `F33f`_`[time`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Time_zone]`_`f (either in `F33f`_`[12-hour format`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=12-hour_clock]`_`f or `F33f`_`[24-hour format`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=24-hour_clock]`_`f), the `F33f`_`[year`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Year]`_`f (e.g. 2012), and sometimes the `F33f`_`[time zone`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Time_zone]`_`f (e.g. `F33f`_`[EST`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Eastern_Standard_Time_(North_America)]`_`f).

A sample reply for a `B100`F9d9CTCP TIME`f`b request to a target that uses the `F33f`_`[ChatZilla`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=ChatZilla]`_`f client is:

`B100`F9d9TIME Fri 23 Nov 2012 19:26:42 EST`f`b

>>>PING

A `B100`F9d9CTCP PING`f`b request will determine the `F33f`_`[ping rate`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Ping_(networking_utility)]`_`f that directly exists between two clients (i.e. discounting the server). The `B100`F9d9CTCP PING`f`b command works by sending an (often) `F33f`_`[integer`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Integer_(computer_science)]`_`f `F33f`_`[argument`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Argument_(computer_science)]`_`f (a `F33f`_`[timestamp`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Timestamp]`_`f) to a target client, the target client then responds by supplying exactly the same numerical parameter. The `F33f`_`[difference`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Subtraction]`_`f between the original timestamp and the current timestamp is calculated, with the result being displayed to the user that initiated the `*CTCP PING`*. More often than not, a timestamp that utilises `F33f`_`[milliseconds`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Milliseconds]`_`f is used due to the majority of users with `F33f`_`[broadband`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Broadband]`_`f Internet connections having a ping under 1 second.

A sample `B100`F9d9CTCP PING`f`b request to target `*<nickname>`* from the `F33f`_`[XChat`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=XChat]`_`f client is:

`B100`F9d9CTCP PING 23152511`f`b

Likewise, sample output generated from the difference (see above) is:

`B100`F9d9Ping reply from <nickname>: 0.53 second(s)`f`b

>>>DCC CHAT

The CHAT service enables users to chat with each other over a DCC connection.`:cite-ref-4[`F5bf`_`[4`#cite-note-4]`_`f] The traffic will go directly between the users, and not over the IRC network. When compared to sending messages normally, this reduces IRC network load, allows sending of larger amounts of text at once, due to the lack of flood control, and makes the communication more secure by not exposing the message to the IRC servers (however, the message is still in `F33f`_`[plaintext`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Plaintext]`_`f).

DCC CHAT is normally initiated using a `F33f`_`[CTCP`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Client-To-Client_Protocol]`_`f handshake. The user wishing to establish the connection sends the following CTCP to the target, `B100`F9d9DCC CHAT `*protocol`* `*ip`* `*port`*`f`b, where `*ip`* and `*port`* are the IP address and port number of the sender, and are expressed as integers. `*protocol`* is chat for standard DCC CHAT. The receiving party can then connect to the given port and IP address.

Once a connection is established, the protocol used for DCC CHAT is very simple: users exchange `F33f`_`[CRLF`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=CRLF]`_`f-terminated messages. Messages that begin with an `F33f`_`[ASCII`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=ASCII]`_`f 001 (control-A, represented below by [^A]) and the word ACTION, and are terminated by another ASCII 001, are interpreted as emotes: `B100`F9d9[^A]ACTION waves goodbye[^A]`f`b.

>>>>DCC Whiteboard

This is an extension to DCC CHAT, allowing simple drawing commands to be sent as well as lines of text. DCC Whiteboard is initiated with a handshake similar to DCC CHAT, with the protocol chat replaced by wboard: `B100`F9d9DCC CHAT wboard `*ip`* `*port`*`f`b.

Once the connection is established, the two clients exchange `F33f`_`[CRLF`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=CRLF]`_`f-terminated messages. Messages that begin (and optionally end) with ASCII 001 are interpreted as special commands; the command ACTION represents an emote, while others cause lines to be drawn on the user's whiteboard surface, or allow the two clients to negotiate a set of features.

>>>DCC SEND

The SEND service allows users to send files to one another. The original specification for the handshake did not allow the receiver to know the total file size nor to resume a transfer. This has made clients introduce their own extensions to the handshake, many of which have become widely supported.

The original handshake consisted of the sender sending the following CTCP to the receiver: `B100`F9d9DCC SEND `*filename`* `*ip`* `*port`*`f`b.

As with DCC CHAT, `*ip`* and `*port`* are the IP address and port where the sending machine will be listening for an incoming connection. Some clients enclose filenames with spaces in double quotes. It is common practice to add the file size as a last argument: `B100`F9d9DCC SEND `*filename`* `*ip`* `*port`* `*filesize`*`f`b.

At this point, the original specification had the receiver either connect to the given address and port and wait for data, or ignore the request, but for clients supporting the DCC RESUME extension, a third alternative is to ask the sender to skip part of the file by sending the CTCP reply: `B100`F9d9DCC RESUME `*filename`* `*port`* `*position`*`f`b.

If the sending client supports DCC RESUME, it will reply with, `B100`F9d9DCC ACCEPT `*filename`* `*port`* `*position`*`f`b, and the receiver can connect to the given address and port and listen for data to append to an already existing file.

Data is sent to the client in blocks, each of which the client must acknowledge by sending the total number of bytes received in the form of a `F33f`_`[32-bit`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=32-bit]`_`f `F33f`_`[network byte order`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Network_byte_order]`_`f integer. This slows down connections and is redundant because of `F33f`_`[TCP`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Transmission_Control_Protocol]`_`f. The send-ahead extension relieves this problem somewhat by not waiting for the acknowledgements, but since the receiver still has to send them for every block it receives, in case the sender expects them, it is not solved completely.

Another extension, TDCC, or turbo DCC, removes the acknowledgements, but requires a slightly modified handshake and is not widely supported. Older versions of TDCC replaced the word SEND in the handshake with TSEND; later versions use the word SEND but append a T after the handshake, making this version of TSEND compatible with other clients (as long as they can parse the modified handshake).

>>>>DCC SEND exploit

The "DCC send exploit" can refer to two bugs: a variant `F33f`_`[buffer overflow`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Buffer_overflow]`_`f error in `F33f`_`[mIRC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=MIRC]`_`f triggered by filenames longer than 14 characters,`:cite-ref-5[`F5bf`_`[5`#cite-note-5]`_`f] and an input validation error in some routers manufactured by `F33f`_`[Netgear`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Netgear]`_`f, `F33f`_`[D-Link`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=D-Link]`_`f and `F33f`_`[Linksys`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Linksys]`_`f, triggered by the use of port 0.`:cite-ref-6[`F5bf`_`[6`#cite-note-6]`_`f]`:cite-ref-7[`F5bf`_`[7`#cite-note-7]`_`f] The router exploit, in particular, may be triggered when the phrase 'DCC SEND' followed by at least 6 characters without spaces or newlines appears anywhere in a `F33f`_`[TCP`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Transmission_Control_Protocol]`_`f stream on port 6667, not just when an actual DCC SEND request has been made. In the 2000s it was possible to combine multiple exploits into a single string, DCC SEND startkeylogger 0 0 0, which if posted in a public channel could cause multiple users to disconnect (either by crashing IRC clients, crashing routers, or triggering overly strict default settings in antivirus software).

>>>DCC XMIT

The XMIT service is a modified version of DCC SEND that allows for resuming files and cuts down on wasteful traffic from the ACK longs. XMIT is not widely supported.

The XMIT handshake differs somewhat from the SEND handshake. The sender sends a offering a file to the receiver: `B100`F9d9DCC XMIT `*protocol`* `*ip`* `*port`*[ `*name`*[ `*size`*[ `*MIME-type`*]]]`f`b

Square brackets here enclose optional parts. `*protocol`* is the `F33f`_`[protocol`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Protocol_(computing)]`_`f to use for the transfer; only clear is defined presently. Unlike standard DCC SEND, `*ip`* can be in the additional forms of standard dotted notation for IPv4, or either hexadecimal or mixed notation for IPv6. To leave an early parameter empty, but still supply a later one, the earlier one can be specified as -. If the receiver does not implement the protocol used, it will send back a CTCP reply of the format: `B100`F9d9ERRMSG DCC CHAT `*protocol`* unavailable`f`b.

CHAT is used here to maintain compatibility with the error messages sent by the extended DCC CHAT. If the receiver declines the transfer, it sends the following CTCP reply: `B100`F9d9ERRMSG DCC CHAT `*protocol`* declined`f`b.

Other errors are reported in the same fashion. If the receiver is willing and capable of receiving the file, it will connect to the given address and port. What happens then depends on the protocol used.

In the case of the clear protocol, the XMIT server will, upon receiving a connection, send a 32-bit `B100`F9d9`F33f`_`[time t`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Time_t]`_`f`f`b in `F33f`_`[network byte order`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Network_byte_order]`_`f, representing the file's modification time. Presumably based on the modification time of the local file, the client will then send another network byte order `B100`F9d9`F33f`_`[long`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Endianness]`_`f`f`b, an offset which the server should seek to when sending the file. This should be set to zero if the whole file is wanted, or the size of the local file if the client wishes to resume a previous download.

While faster than SEND, XMIT carries one of the same limitations in that it is impossible to tell how big the file is, unless its size is specified in the negotiation or known beforehand. Furthermore, it is not possible to resume a file past the two gigabyte mark due to the 32-bit offset.

>>>Passive DCC

In a normal DCC connection the initiator acts as the `F33f`_`[server`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Server_(computing)]`_`f, and the target is the `F33f`_`[client`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Client_(computing)]`_`f. Because of widespread `F33f`_`[firewalling`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Firewall_(networking)]`_`f and reduction of end-to-end transparency because of `F33f`_`[NAT`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Network_Address_Translation]`_`f, the initiator might not be able to act as a server. Various ways of asking the target to act as the server have been devised:

>>>>DCC Server

This extension to normal DCC SEND and CHAT was introduced by the IRC client `F33f`_`[mIRC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=MIRC]`_`f. DCC Server has moderate support, but is not standard on all clients (see `F33f`_`[Comparison of Internet Relay Chat clients`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Comparison_of_Internet_Relay_Chat_clients]`_`f).

It allows the initiation of a DCC connection by IP address, without the need of an IRC server. This is accomplished by the receiving client acting as a server (hence the name) listening (usually on port 59) for a handshake from the sender.

For a CHAT, the initiator sends `B100`F9d91000 `*initiator nick`*`f`b. The target then replies with, `B100`F9d91000 `*target nick`*`f`b, and the rest proceeds according to standard DCC CHAT protocol.

For a SEND, the initiator sends `B100`F9d91200 `*initiator nick`* `*filesize`* `*filename`*`f`b. The target replies with, `B100`F9d91210 `*target nick`* `*resume position`*`f`b, where `*resume position`* is the offset in the file from which to start. From here the transfer proceeds as a normal DCC SEND.

DCC Server also supports mIRC-style file servers and DCC GET.

>>>>RDCC

DCC Server provides no way specifying the port to use, so this has to be negotiated manually, which is not always possible, as one of the sides may not be a human. RDCC is a handshake mechanism for DCC Server, which in addition to the port also provides the IP address of the server, which the client might not be able to find otherwise because of host masking. It is not widely supported.

The initiator requests the port the target is listening on by sending the CTCP query, `B100`F9d9RDCC `*function`* `*comment`*`f`b, where `*function`* is c for chat, s for send, or f for file server.

The target may then CTCP reply with, `B100`F9d9RDCC 0 `*ip`* `*port`*`f`b, where `*ip`* and `*port`* have the same meanings as for normal DCC SEND and CHAT. After this the initiator connects to the `*ip`* and `*port`*, and a DCC Server handshake follows.

>>>>DCC REVERSE

Unlike DCC Server, where the handshake is handled over a direct IP connection, DCC REVERSE has a normal CTCP handshake, similar to the one used by DCC SEND. This is not widely implemented. The sender offers a file to the receiver by sending the CTCP message: `B100`F9d9DCC REVERSE `*filename`* `*filesize`* `*key`*`f`b. `*key`* is a 1–50 characters-long string of `F33f`_`[ASCII`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=ASCII]`_`f characters in the range 33–126, and acts as an identifier for the transfer.

If the receiver accepts, it sends the CTCP reply, `B100`F9d9DCC REVERSE `*key`* `*start`* `*ip`* `*port`*`f`b

Here, `*start`* is the position in the file from which to start sending, `*ip`* is the IP address of the receiver in standard `F33f`_`[dotted notation`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Dot-decimal_notation]`_`f for `F33f`_`[IPv4`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=IPv4]`_`f, or `F33f`_`[hexadecimal`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Hexadecimal]`_`f notation for `F33f`_`[IPv6`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=IPv6]`_`f. The sender then connects to the ip address and port indicated by the receiver, and a normal DCC SEND follows. Both the sender and receiver can cancel the handshake by sending the CTCP reply, `B100`F9d9DCC REJECT REVERSE `*key`*`f`b.

>>>>DCC RSEND

This is the KVIrc client's alternative to DCC REVERSE. The sender offers a file by sending the CTCP: `B100`F9d9DCC RSEND `*filename`* `*filesize`*`f`b. The receiver can then accept by CTCP replying with, `B100`F9d9DCC RECV `*filename`* `*ip`* `*port`* `*start`*`f`b, and the sender connects to the receiver and sends as during a normal DCC SEND.

>>>>Reverse / Firewall DCC

This passive DCC mechanism is supported by at least `F33f`_`[mIRC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=MIRC]`_`f, `F33f`_`[Visual IRC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Visual_IRC]`_`f, `F33f`_`[HexChat`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=HexChat]`_`f, KVIrc, `F33f`_`[DMDirc`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=DMDirc]`_`f, Klient, `F33f`_`[Konversation`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Konversation]`_`f, and PhibianIRC. The sender offers a file by sending the CTCP message, `B100`F9d9DCC SEND `*filename`* `*ip`* 0 `*filesize`* `*token`*`f`b. `*ip`* is the `F33f`_`[IP address`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=IP_address]`_`f of the sender in network byte order, expressed as a single integer (as in standard DCC). The number 0 is sent instead of a valid port, signaling that this is a Reverse DCC request. `*token`* is a unique integer; if TSEND is being used (by a client that supports it), the letter T is appended to the token, letting the receiver know it doesn't need to send acknowledgements.

The receiver can accept the file by opening a listening socket and responding with the CTCP message, `B100`F9d9DCC SEND `*filename`* `*ip`* `*port`* `*filesize`* `*token`*`f`b. This is identical to the original Reverse DCC message, except the `*ip`* and `*port`* identify the socket where the receiver is listening. `*token`* is the same as in the original request, letting the sender know which request is being accepted. (Because this message follows the same format as a regular DCC send request, some servers which filter DCC requests may require the sender to add the receiver to their "DCC allow" list.)

The sender then connects to the receiver's socket, sends the content of the file, and waits for the receiver to close the socket when the file is finished.

When the RESUME extension to the SEND protocol is used, the sequence of commands becomes (with >> indicating an outgoing message on the initiating side, and << response by its peer):

`B100`F9d9>> DCC SEND `*filename`* `*ip`* 0 `*filesize`* `*token`*

\<< DCC RESUME `*filename`* 0 `*position`* `*token`*

\>> DCC ACCEPT `*filename`* 0 `*position`* `*token`*

\<< DCC SEND `*filename`* `*peer-ip`* `*port`* `*filesize`* `*token`*`f`b

After which the protocol proceeds as normal (i.e. the sender connects to the receiver's socket).

>>>File servers (FSERVs)

A DCC `*fserve`*, or file server, lets a user browse, read and download files located on a DCC server.

Typically, this is implemented with a DCC CHAT session (which presents the user with a command prompt) or special commands to request a file. The files are sent over DCC SEND or DCC XMIT. There are many implementations of DCC file servers, among them is the FSERV command in the popular `F33f`_`[mIRC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=MIRC]`_`f client.

>>See also

• `F33f`_`[Internet Relay Chat`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Internet_Relay_Chat]`_`f (IRC)

• `F33f`_`[IRC client`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Internet_Relay_Chat]`_`f

• `F33f`_`[Comparison of Internet Relay Chat clients`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Comparison_of_Internet_Relay_Chat_clients]`_`f

• `F33f`_`[DCC`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=Direct_Client-to-Client]`_`f (Direct Client-to-Client)

>>References

`:cite-note-1`!1.`! `F0af`_`[↑`#cite-ref-1]`_`f `:citerefpiccardbrian-baskingeorge-spillmanmarcus-sachs2005`aPiccard, Paul; Brian Baskin; George Spillman; Marcus Sachs (May 1, 2005). "IRC Networks and Security". `*Securing IM and P2P Applications for the Enterprise`* (1st ed.). Syngress. p. 386. `F33f`_`[ISBN`:/page/wikibook/entry.mu`zim=wikipedia_en_all_nopic_2025-08.zim|entry_path=ISBN_(identifier)]`_`f 1-59749-017-2. The authors of the ircII software package originally pioneered file transfers over IRC.

`:cite-note-2`!2.`! `F0af`_`[↑`#cite-ref-2]`_`f See the 'NOTES' and 'source/ctcp.c' files included with ircii-2.1.4e.tar.gz

`:cite-note-3`!3.`! `F0af`_`[↑`#cite-ref-3]`_`f See the 'UPDATES' and 'source/dcc.c' files included with ircii-2.1.4e.tar.gz

`:cite-note-4`!4.`! `F0af`_`[↑`#cite-ref-4]`_`f "mIRC Help". `*www.mirc.com`*. Retrieved 2023-07-24.

`:cite-note-5`!5.`! `F0af`_`[↑`#cite-ref-5]`_`f "SecurityFocus exploit information".

`:cite-note-6`!6.`! `F0af`_`[↑`#cite-ref-6]`_`f "CVE - CVE-2006-1068". `*cve.mitre.org`*.

`:cite-note-7`!7.`! `F0af`_`[↑`#cite-ref-7]`_`f "CVE - CVE-2006-1067". `*cve.mitre.org`*.

>>External links

• CTCP Details

`c`F0af`_`[↑ Back to top`#top]`_`f`a